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SYSTEM AND METHOD FOR ROUTING BOTH TOLL-FREE AND CALLER-PAID 
TELEPHONE CALLS TO CALL SERVICE CENTERS 

BACKGROUND OF THE INVENTION 

The present invention relates to managing telephone calls directed to call 
5 service centers. More particularly, the present invention relates to a system and 
method for routing both toll-free and caller-paid telephone calls to call servicing 
centers. 

Many business enterprises make use of toll-free numbers, such as 800, 877 
or 888 numbers, to provide customers with call services that allow customers to dial 

10 in and speak to company representatives or hear a recording. The call service is 
supported by one or more call service centers that may handle such functions as 
product ordering, dissemination of product information, or general company 
information. Customers typically expect prompt attention to their inquiries and thus 
may avoid doing business with companies that use telephone services which place 

15 customers on hold for extended periods of time. Both the customer and the 

company providing the call service desire efficient call distribution and handling. 

If a company has a call service that uses a single call center with a group of 
agents available at one location, the company provides its customers with a toll-free 
number that is routed to an automatic call distribution device(ACD). The ACD is 

20 linked to the various agents at the call service center and can route calls based on 
agent availability and expertise. While this method of call distribution is effective for 
handling telephone calls directed to a single call center having agents in the same 
geographical area, it does not address the need for handling calls over a toll-free 
line to a business enterprise having multiple call centers in various geographical 

25 locations. 

One solution to managing multiple call service centers that are geographically 
dispersed is provided by the GEOTEL Intelligent CallRoufeA® (ICR). The ICR 
service provides interfaces to multiple carrier networks and provides call routing to 
agents at call service centers independent of the particular toll-free network provider 
30 used. Present telephone systems utilize the ICR to manage incoming call center 
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traffic over toll-free lines and do not address caller-paid calls (i.e., calls billed to the 
caller). Business enterprises that offer call services may wish to use a local 
telephone number to maintain a local presence to their customers even though the 
local number may connect to a call service center in another geographical location. 
5 Additionally, toll-free numbers can be a large expense for a business enterprise and 
some businesses may choose to convert more of their telephone traffic to regular 
telephone numbers if the local (caller-paid) numbers can offer the same level of 
service to their calling customers. 

Accordingly, there is a need for an improved system and method for 
10 managing call distribution to call service centers that can handle both caller-paid and 
toll-free telephone calls. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is an illustration of a system for managing caller-paid and toll-free 
telephone calls according to one embodiment of the invention; 
15 FIG. 2 is a block diagram of an advanced intelligent network for use in the 

system of FIG. 1; 

FIG. 3 is a block diagram of an intelligent processing platform interface; 

FIG. 4 is a flow diagram showing a preferred method of processing a caller- 
paid telephone call using the system of FIG. 1 ; 
20 FIG. 5 is a flow diagram of an alternative method of processing a caller-paid 

telephone call in an advanced intelligent network; 

FIG. 6 is a flow diagram of a third alternative embodiment of a method of 
processing a caller-paid telephone call in an advanced intelligent network. 

DETAILED DESCRIPTION OF THE 
25 PRESENTLY PREFERRED EMBODIMENTS 

Figure 1 illustrates an embodiment of a system for routing both toll-free and 

caller-paid telephone calls according to the present invention. The system 10 

includes one or more interexchange networks 12, a local exchange network 14 and 

an intelligent processing platform (IPP) 16. The interexchange networks 12 may be 

30 any one of a number of telephone systems that handle toll-free telephone calls, 

typically 800, 877 or 888 telephone calls, and handle transport of telephone calls 
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across local access transport area (LATA) boundaries. The interexchange networks 
12 communicate with the IPP 16 via data channels 18. The interexchange networks 
12 carry telephone voice and data information over voice channels 20. The local 
exchange network 14 also communicates with the IPP 16 via a data channel 22. 
5 Voice and information from a caller utilizing a local exchange network 14 is 
transmitted over voice lines 24. 

The system 10 also includes a call service having at least two call service 
centers 26 positioned in different geographical locations. Each call service center 26 
includes a group of agents 28. An automatic call distributor (ACD) 30 receives data 

10 information regarding the voice lines 20, 24 utilized by the local exchange network 
14 or interexchange network 12. The ACD 30 also routes the incoming call to the 
appropriate agent 28. The ACD 30 keeps track of, among other things, the status of 
agents and the estimated wait time for reaching an agent. Any of a number of 
commonly available ACDs may be used. Examples of suitable ACDs 30 are the 

15 Lucent Technologies Definity ACD and the Meridian from Northern Telecom Limited. 
In one alternative embodiment, a local central office switch such as a Lucent 
Technologies 5ESS may provide the services of a typical ACD. The ACD 30 may be 
a stand-alone device or integrated with a private branch exchange (PBX). 

Each ACD 30 is preferably connected to a gateway 32 via a datalink 34. The 

20 gateway 32 is also linked via a data line 36 to the IPP 16. Each gateway 32 

contains software specific to the type of ACD 30 capable of translating agent status 
information maintained at the ACD 30 into a format understandable by the IPP 16. 
In this manner, various types of ACDs 30 may be used in the system 10. The IPP 
16 may be a single processor or a distributed network maintaining a log of agent 28 

25 status at the various geographical locations based on information provided from the 
ACDs 30 to the gateway 32. The IPP 16 processes the information from the 
gateways 32 to provide a centralized control of call distribution from the 
interexchange networks 12 and local exchange network 14. Suitable devices for the 
IPP may be a GeoTel Communications ICR or a Genesys Telecommunication 

30 Laboratories Intelligent Call Distributor. 

FIG. 2 illustrates a preferred local exchange network 14 having advanced 
intelligent network (AIN) capabilities. The local exchange network 14 includes one 
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or more end office switches equipped as AIN service switching points (SSP) 38. 
The SSP 38 is a programmable switch having the ability to recognize AIN triggers for 
calls requiring special services. The SSP 38 may be an end office or tandem switch 
and communicates with a service control point (SCP) 40. An end user may be 
5 connected to the SSP 38 over a voice/information channel 24 such as an ordinary 
telephone line. Multiple connections and combinations of network elements are 
usable in the local exchange network 14. For example, an end user may also 
connect to an SSP 38 through one or more ordinary telephone switches. 

The SCP 40 is a network element in the AIN local exchange network 14 

10 containing logic and data necessary to provide the functionality required for the 
execution of a desired communication service. An SCP 40 generally permits 
separation of service logic from switching functionality such that additional services 
may be developed without the need to provision software in each individual SSP 38. 
A suitable SCP 40 is the Advantage SCP manufactured by Lucent Technologies. 

15 The SCP 40 is preferably in communication with the SSP 38 via a signal transfer 
point (STP) 42. The STP 42 routes signals between different network elements. A 
suitable data signaling standard for use with the STP is the American National 
Standards Institute (ANSI) signaling system number 7 (SS7). The SCP 40 
preferably communicates with the IPP 16 over a data line 22. The SSP 38 in the 

20 local exchange network 14 may communicate with an intelligent peripheral 44 over a 
data 46 or voice 48 channel. 

The IP 44 is a network element of the AIN that contains resources to 
exchange information with an end user and perform other functions such as call 
origination and tone generation. The IP 44 provides special resources for 

25 interactions between the end user and the network such as dual tone 

multi-frequency (DTMF) recognition, playing pre-recorded announcements and tone 
generation. A service node/intelligent peripheral (SN/IP) platform manufactured by 
Comverse Technology, Inc. is suitable for use with the AIN local exchange network 
14. Although the local exchange network 14 illustrated in FIG. 2 shows only one of 

30 each network element, those of ordinary skill in the art understand that the presently 
preferred system and method may include more complex networks having a plurality 
of interconnected SCPs, IPs, STPs, and SSPs. 
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Referring to FIG. 2, the SCP 40 preferably includes an IPP interface 50 for 
generating messages to, and interpreting messages from, the IPP 16. As shown in 
FIG. 3, the IPP interface 50 generates a routing query message 52 and expects a 
routing response message 54 in return. The routing query message includes a 
5 message header 56 and a transaction ID 58 identifying the type of message and a 
unique number assigned to the telephone call, respectively. The routing query 
message 52 also includes the dialed number 60 and the calling party's number 62. 
The routing query message 52 may optionally include a segment containing 
collected digits 64 so that any digits collected through a play and collect menu in the 

10 local exchange network 14 may be passed on through the agent 28 at the call 

service center 26 assigned to the telephone call. Another optional field in the routing 
query message is an optional parameter field 66 which may be used for future 
expansion and adaptability of the network 10. The routing response message 54 
also includes a header 68 and transaction ID 70 along with the route response 72 

15 generated by the IPP 16. Additionally modified or new parameters 74 are optionally 
included in the message returned by the IPP 16. The route response 72 may be a 
ten digit number or a trunk group identifier with outpulse digits. The IPP interface 50 
also preferably includes default instruction logic 76 for routing a caller-paid 
telephone call originating in the local exchange network to one of the service centers 

20 26 in the event that there is no response from the IPP 16. In one embodiment, the 
interface between the SCP 40 and the IPP is TCP/IP. Other communication 
interfaces, such as SS7 may also be used. 

Utilizing the network 10 described above, a preferred method of utilizing the 
common architecture for routing both caller-paid telephone calls from a local 

25 exchange network 14 and toll free telephone calls from interexchange networks 12 
using an intelligent processing platform 16 is described below. Referring to FIG. 4, a 
caller-paid telephone call in a local exchange network 14 comes in over a voice line 
or trunk to the SSP 38 (at step 76). The telephone call then encounters an AIN 
trigger (at step 78). Recognizing that the telephone call requires AIN processing, the 

30 SSP sends a query to the SCP 40 via the STP 42 for routing instructions (at step 
80). The service logic 51 in the SCP 50 recognizes the call is directed to a call 
service center and will require the generation of a routing query message 52 to 
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query the IPP for routing instructions (at step 82). The SCP next launches the query 
to the IPP 16 (at step 84). The routing query message 52 includes at least the 
dialed number 60. The message may also contain the calling party's number 62 and 
the other information described above. 
5 In an alternative embodiment, the routing query message sent from the SCP 

to the IPP may only include a portion of the calling party's number 62 in order to 
preserve privacy. For example, if the local exchange network containing the SCP is 
owned by a first enterprise and the IPP is owned by a second enterprise, the first 
enterprise may only wish to disclose a portion of the calling party's number to the 

10 IPP. Preferably, the routing query message 52 contains enough of the calling 

party's number, such as the area code or the area code and prefix, to allow the IPP 
to make an informed routing determination. 

In response to the routing query message the IPP accesses the customer 
routing script 63 associated with the dialed number 60. The customer routing script 

15 63 is essentially a flow-chart or a list of rules indicating the actions to be taken when 
the particular dialed number 60 is received. Using the script 63 and information 
about the real-time activities at the customer's call centers 26 gathered by the 
gateways 32, the IPP 16 makes a routing determination (at step 86). The IPP then 
returns the routing destination in the routing response message 54 and sends it to 

20 the SCP 40 (at step 88). The route response 72 may be a 10 digit number or a trunk 
group with outpulse digits. Alternatively, the route response may be an international 
telephone number. The SCP 40 communicates with the SSP 38 over a data line 
connected by the STP communicating the routing destination for a telephone call (at 
step 90). The SSP subsequently routes the call to the indicated routing destination 

25 (at step 92). Separately or concurrently with the one or more telephone calls 

directed to the IPP from the local exchange network 14, the interexchange networks 
12 may also be querying the IPP 16. The IPP 16 preferably gathers all the call 
information generated at the ACDs 30 and transmitted via the gateways 32 to make 
call routing determinations to optimize the use of agents 28 at the various call 

30 service centers 26. 

In instances where there is a failure of communication between the SCP 40 
and IPP 16, the SCP may utilize default instruction logic 76 to determine when 
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default routing should be used. For example, in one embodiment, the SCP may wait 
for a predetermined interval before accessing the default instructions and then will 
route the call to a single predetermined number. Alternatively, the default 
instructions may include directions to send calls to one of several predetermined 
5 numbers on a percent allocation basis. Thus, the SCP would instruct the SSP to 
direct the call to one of a number of predetermined default call center destinations. 

As shown in FIG. 5, an alternative method of processing a caller-paid 
telephone call may include the SSP playing a message and collecting digits of the 
caller's response to the message. As in FIG. 4, when a call comes in to the SSP 

10 and it is recognized as an AIN call and as one destined for a call service center (FIG. 
4, at steps 76-82). In this example, the service logic 51 indicates that a message 
needs to be played to the caller (at step 94). The SCP 40 instructs the SSP to play 
a particular announcement and collect digits from the caller (at step 96). This step 
may be repeated several times depending on the instructions from the SCP 44. In 

15 response to the SCP's instructions, the SSP plays the announcement, collects the 
digits from the caller and passes on the caller-entered digits to the SCP (at step 98). 
The SCP 40 then launches a query to the IPP including at least the dialed number 
60 and the collected digits 64 (at step 100). The IPP 16 then accesses the customer 
routing script 63 associated with the dialed number, and then based on the routing 

20 script, the caller-entered digits and the information on the real time activities at the 
call centers, the IPP makes a routing determination at step 102. As discussed 
earlier, the IPP returns the destination and the call is routed to the appropriate 
destination (at steps 88-92). 

FIG. 6 illustrates an example where an external resource other than an SSP 

25 is used interact with the call. As before, the call is first recognized as an AIN call 
(FIG. 4, at steps 76-82). In this case, however, the service logic 51 indicates that a 
menu announcement should be played to the caller using an external source such 
as an IP 44 (at step 102). The SCP 40 then sends instructions to the IP over the 
data link 46 (via the SSP) indicating that a particular announcement or 

30 announcements should be played and digits collected from the caller (at step 104). 
The IP plays the announcements, collects the digits, and then passes the 
caller-entered digits to the SCP (at step 106). The SCP 40 then launches a query to 
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the IPP including at least the dialed number 60 and the collected digits 64 (at step 
108). Subsequently, the IPP 16 accesses the customer routing script 63 associated 
with the dialed number and returns a routing destination to the SCP in a routing 
response message 54. The SSP then routes the call to the appropriate destination. 
5 The present system and method provide flexibility and advantages over the 

prior art. Business enterprises that are customers of local exchange networks may 
utilize the present common architecture for directing both local calls and 
long-distance calls through the common control of the IPP to reduce costs and 
maintain a local presence while still retaining the advantage of a centralized call 

10 distribution network. Thus not only can the same architecture be used, but the calls 
may be directed through common routing scripts. 

Alternative embodiments include connecting to an interexchange network 
number rather than an interexchange network SCP so that the interexchange 
network toll-free number will route to a regular local number and then use the local 

15 exchange network SCP in a manner similar to that described previously. The caller 
interaction with a play and collect menu that occurs in the local exchange network 14 
prior to the SCP querying the IPP for routing instructions can offer a time and cost 
savings to the business enterprise supporting the customer call service centers. 
According to an aspect of the present invention, the SCP for the local exchange 

20 network can pass a presentation restriction indicator (i.e., a caller ID block) and 

other information such as the originating station type (e.g., a pay phone, hotel/motel, 
etc.). With this information, the routing scripts in the IPP can treat calls differently if 
desired. Also, the AIN trigger may be a 3/6/10 digit public office dialing plan trigger, 
a specific digit string trigger, or a termination attempt trigger. The 3/6/10 digit public 

25 office dialing plan refers to triggering on a 3 digit number (area code), a 6 digit 
number (area code + prefix), or an entire 10 digit telephone number. 

The system described above may be programmed to allow the AIN service 
logic 51 to only query for routing instructions in certain cases and not others. For 
example, the service logic 51 may specify that the SCP query for fifty percent of the 

30 calls and route the other calls to the dialed number. In other embodiments, the SCP 
40 may query the IPP for further routing instructions in the event that an initial 
routing instruction given by the IPP results in a busy signal or no answer. In this 
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case, the SCP will indicate to the IPP that a busy signal or no answer was 
encountered. 

It is intended that the foregoing detailed description be regarded as illustrative 
rather than limiting and that it be understood that the following claims, including all 
5 equivalents, are intended to define the scope of this invention. 
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